Subject: RE: Chen's & Peter's notes

From: "Hildebrand, Jeff" <[email-masked]>
Date: Wed, 23 Feb 94 19:40:00 PST

I would appreciate any help with the text for page 10 & page 33 see below
Thanks for the input,
Jeff
 ----------
From: Chung-Huy Chen (254-4827 T/L 444)
To: jhild
Date: Wednesday, February 23, 1994 11:54AM

 -------------------------------------------------------------------------
Date: 21 February 1994, 17:13:01 EST
From: Chung-Huy Chen            254-4827  T/L 444    CHUNGHUY at RALVM6
To:   ciw-sig-adc at ibmstandards.cary.ibm.com
Subject: Comments to Jeff's proposal

  I agree to most of the comments made by Peter Binninger in a note dated
  2/17.  In the following, I will state only comments in addition to
  Peter's or those that are different from his.
  (The page numbers are based on Jeff's proposal although they appear to
   be different from the latest CIW draft (dated 12/15/93).)

                      * * *
  1) Page 10 (Definition of the mapped conversation)
  This section is a proper place to link the notion of a map name to
  the mapped conversation.  But the proposal provides no introduction
  for a map name.  Therefore, I would like to see the following questions
  being answered:
    - What is a map name referred to in SNA and in OSI?
    - What is the uniqueness of a map name in SNA and in OSI?
    - How is a map name related to the encoding used by the local system
      and that used by the network?

> --------------------- Suggested text -----------------------
Delet my first fix for page 10 - leave current definition for mapped 
converation - 2 line
bullet.

Page 10: add note 3

3.A mapped conversation allows two programs to exchange data records in a 
manner
that insulates a program from concerns about how the partner program views 
the data
record.  This is accomplished by encoding and decoding data records using 
routines
that are external to the user application.  These routines can be written by 
a systems
administrator, some other qualified group, or a vendor.  The MAP_NAME is 
used to
access the correct routine.  Within the SNA architecture this would be a 
separate
routine which the underlying layers would access.  A particular 
implementation may
either have the user link edit the routine into the application program or 
use dynamic
link libraries, to the end user the results are the same.  Within the OSI 
architecture this
name would instruct the U-ASE (the OSI TP entity responsible for encoding 
and
decoding user data) what specific U-ASE ASN.1 structure to use.  When a data 
record
is received the reverse process occurs with the decoder recognizing what it 
received
and generating the appropriate local MAP_NAME
.
When an application program is moving data between homogeneous systems and
intends to perform all maipulation of the data within the application 
program itself,  it
may use the network like a pipe and simply send and receive buffers of data. 
 This is
accomplished by specifing CM_MAPPED_CONVERSATION, not supplying a
MAP_NAME or supplying one with all blanks, and supplying the appropriate 
routine.
The SNA routine is the vendor installed routine which supports CPI 
Communications
version 1.0 mapped conversations.  The OSI routine is the Unstructured Data 
Transfer
U-ASE (UDT).

The MAP_NAME is a, 1 - 64 character, local name defined by the person who 
wrote
the encode/decode routine.  Both sides of the conversation could have 
different local
names for the same mapping function.  This might occur when a transaction 
traveled
across an organizational boundary where the naming could not be coordinated. 
 A
good example would be two companies which use an industry standard data 
record
and have independently created a MAP_NAME for the data record..SNA maps the
local MAP_NAME to a globally unique network MAP_NAME.  The globally unique
name is provided by a responsible systems administrator.  OSI uses the 
application
context to define, among other things, the abstract syntax's (ASN.1 
encodings) the
conversation can use.  The MAP_NAME is a local name established by a systems 

administrator for the U-ASE to identify what encoding to use.  Again, the 
two
different systems may have different MAP_NAMES.  Unlike SNA, OSI does not
transmit a MAP_NAME across the network.  Instead the self defining nature of 

ASN.1 automatically performs this function.

The encode/decode routines need not be mirror images of each other.  The 
ability to
manipulate the user data before it is sent or received by the application 
program
allows the application programmer to be insulated from the network.  The 
receiver
may only require a subset of the data that was sent, so only specific fields 
are
delivered to the program.  This allows changes in the data a program sends 
to occur
without requiring every receiving program to change, only the decoding 
routines need
change.  The sending program may only send a subset of the required data 
with the
encoding routine filling in the missing fields.

> --------------------- end suggested text ----------------------

   2) Page 33 (Data conversion section)
   That the proposal merely includes pointers to two new calls is not
   sufficient.  I think the section should describe, from user's
   perspective, how these two calls can be used.

   In addition, the proposal mentions nothing about initialization data
   and expedited data.  I would like to see this requirement question
   being addressed.
>
> I need to check the OSI protocol but initialized data should work just 
fine.
>
> Expedited data would be impossible.  It is only available under SNA so it 
would
> be hard to accomidate.  The discussion at the last CIW seemed to 
discourage this course
>of action.

> ------------------------ suggested text ----------------------------
Page 33: change in 2.11 Data Conversion, second paragraph, last sentence to: 
 These calls
may be used to write a program which is independent of partner program's 
local
character set.

Page 33: add after last paragraph of Data Conversion.

With the SET_MAP_NAME and EXTRACT_MAP_NAME calls, CPI
Communications provides sophisticated data for conversion of data in the 
user buffer.
These routines may be used to write programs that are independent of the 
encoding of
the partner program.  This allows the encode/decode routine to change the 
order of the
fields, selectively receive fields, and supply missing fields when sending.

These calls should not be used when using the OSI Unstructured Data Transfer 
U-
ASE or CPI Communications version 1.0 mapped conversations.  If the user 
desires
to use these calls for uniformity with other programs the SET_MAP_NAME 
should
be set to Blanks.  The EXTRACT_MAP_NAME will return blanks.

         *  Before issuing a SEND_DATA call, the program may issue a 
SET_MAP_NAME
             call to instruct CPI Communications how it should prepare the 
data for
             transmission.   If a MAP_NAME is repeatedly used it only has to 
specified on the
             first occurrence.

       * After receiving data from a Receive call, the program may issue the 

           EXTRACT_MAP_NAME to learn what data record was received.  This 
name can
           be used to direct the application to the proper application logic 
to handle the
            incoming data.  The user should use this call after every 
Receive  unless the
          program knows what record type it is receiving, for example, from 
a batch of
         identical transactions.

See usage notes under 4.xx " SET_MAP_NAME (CMSTMP)" on page yyy and 4.yy
"EXTRACT_MAP_NAME (CMEXMP)" on page zzz.

> ------------------------- end suggested text -----------------------

   3) On the proposed new calls
      a) I agree with Peter that they belong to some conformance class.
         Therefore, I suggest that a CM_CALL_NOT_SUPPORTED return code
         be added to both calls.
> OK

      b) To be consistent with the existing definitions, I suggest
         CM_PROGRAM_PARAMETER_CHECK be used for the errors occurred
         in the map_name parameter.  (CM_PARAMETER_ERROR has a
         different meaning and is currently defined for the CMALLC
         call only.)
> OK
      c) The notion of "default map name" was used in the description
         of the calls but was not explained in the chap. 2 Terms and
         Concepts.  If a default map name exists, who defined it?
         And when was it defined?
> I think Peter is right the default name should go.  No name or a blank
>name should be used only with UDT and CPIC 1.0 mapped conversations.
> all other should be required to give a name.

         It also seems to be somewhat contradictory to the early part
         of the proposal, where "Not set" is indicated for all four
         cases for the map_name in the Characteristics and their
         default values table.

      d) I also support map_name be represented in character format.
         A related question is which character set is a map name
         drawn?
> I would select the stad IBM character set for SNA and
>T61 strings for OSI..

   4) This is a general question.  I believe a complete proposal
      should also include a working example for both SNA and OSI
      and provide information for the implementers such as:
      - what is defined at development time and who defines it?
      - what is needed at the runtime and where to find it?

                  * * *
> What type of text would you suggest and where would it go.
> These are implemtation issues which are vendor specific -
> I don't think the specification should go into the area.
>

   Regards,
   Chung-Huy Chen

 ----------------------------------------------------------------------------  
 --
Received: from ibmstandards.cary.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R2)
   with TCP; Tue, 22 Feb 94 07:35:20 EST
Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.35.17.2]
with SMTP
        id AA148299; Tue, 22 Feb 94 06:30:54 -0500
From: [email-masked]
Received: from D018S100.mch.sni.de by thoth.mch.sni.de with SMTP id AA11955
  (5.67a/IDA-1.5 for
<[email-masked]>); Tue, 22 Feb 1994
12:44:46 +0100
Received: from d018s100.mch.sni.de by d018s100.mch.sni.de
          at Tue, 22 Feb 94 12:44:19  +0100 (5.52.1/SIE-1.1)
Message-Id: <[email-masked]>
Date: Tue, 22 Feb 94 12:44:19  +0100
Subject: Comments to Jeff's proposal and Chung's comments
Apparently-To: [email-masked]
Apparently-To: <NSAECHO@ralvm6>
Apparently-To: <CHUNGHUY@ralvm6>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <MITCH1@ralvmg>
Apparently-To: <[email-masked]>

I agree with Chung, that the CPI-C document should describe,
what is a map name in SNA and OSI.

And I also agree with Chung, that there should also be some
information for implementors.
>Like What?

SNI is extending it's transaction monitor UTM with OSI TP functions.
And we want to offer a possibility that users can define their own
abstract syntax. At the moment SNI does not plan to offer this functions
with the CPI-C interface. But the problems with our programming interface
are similar to those of CPI-C. Our solution is as follows:

  The administrator has to define every abstract syntax used in the
  monitor. An abstract syntax is defined by it's object identifier.
  The administrator also has to give a 1 to 8 byte character name to each
  abstract syntax. He also can define some transfer syntaxes to every
  abstract syntax.

  According to OSI on association establishment both partners must
  negotiate the set of abstract syntaxes and the transfer syntaxes.

  If a program wants to send user data it must use a map name.
  A map name consisting of 8 blanks means that UDT is used
  as abstract syntax. If the program wants to use any other abstract
  syntax, it has to use the administrator defined abstract syntax name
  as map name. Decoding and encoding is the job of the user program.
  The transaction monitor uses the map name to send the user data with
  the suitable presentation context id.

This is not exactly the solution of Jeff's proposal, because
decoding and encoding is the job of the user program.
But it makes clear that the CPI-C document should contain some similiar
information for implementors.

So i want to answer Chung's question 'What is a map name in OSI?'
as follows:

  A map name is a local defined name representing an abstract syntax.
  If a program uses no map names, UDT is used as abstract syntax.

This means that I want to change Jeff's proposal concerning the
standard value of a map name. Jeff's proposal was the following:

  If there is only one abstract syntax allowed on the association,
  this is the standard value.
  If there are more abstract syntaxes allowed, there is no standard
  value. The map name is mandatory.

My proposal:

  If programs use no map name, UDT is taken as abstract syntax.
  If UDT is not allowed on this association, the Set_Map_Name returns
  with CM_PROGRAM_PARAMETER_CHECK.
  If programs want to use other abstract syntaxes they have to
  use map names. If the use a map name not defined by the administrator
  or not allowed on this association, the Set_Map_Name returns
  with CM_PROGRAM_PARAMETER_CHECK.
>
> You can't assume UDT.  If the application context does not support it
> could not be used.  Iy is possible to have two U-ASEs, one
>for regular encodings and UDT, but I would think
> it would be confusing.
> How would differentiate which U-ASE you were addressing?

Peter

 -----------------------------------------------------------------------------
Peter Binninger                         Voice: (+49) 7531-87-4758
Computer Gesellschaft Konstanz mbH      Fax:   (+49) 7531-87-4888
(Siemens Nixdorf Informationssysteme)   Email: [email-masked]
Max-Stromeyer-Strasse 116
78467 Konstanz
Germany